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ABSTRACT 

Fixed or static limit sensing is employed in control 
centers to ensure that spacecraft parameters remain 
within a nominal range. However, many critical 
parameters, such as power system telemetry, are 
time-varying and, as such, their "nominal" range is 
necessarily time-varying as well. 

Predicted data, manual limits checking, and widened 
limit-checking ranges are often employed in an 
attempt to monitor these parameters without 
generating excessive limits violations. Generating 
predicted data and manual limits checking are both 
resource intensive, while broadening limit ranges for 
time- varying parameters is clearly inadequate to 
detect all but catastrophic problems. 

OSA provides a low-cost solution by using 
analytically selected data as a reference upon which 
to base its limits. These limits are always defined 
relative to the time- varying reference data, rather 
than as fixed upper and lower limits. In effect, OSA 
provides individual limits tailored to each value 
throughout all the data. A side benefit of using 
relative limits is that they automatically adjust to 
new reference data. In addition, OSA provides a 
wealth of analytical by-products in its execution. 

Key Words: Orbital signature, limit sensing, 
telemetry, spacecraft 


1. INTRODUCTION 

The responsibility of the control center is to maintain 
the health and safety of the spacecraft. Controllers 
utilizing traditional tools routinely perform a real- 
time rudimentary state of health assessment. This 
assessment is only as good as the available tools, 
analytical quality of the databases they access and 
the controllers that use them. Early detection and 
response to potential problems increases the 
probability of meeting mission objectives. 

Traditional tools are limited and resource intensive. 
Only limit sensing provides a broad continuous 
assessment of spacecraft condition on the ground. 
While accurate assessment of bi-level states and 
slightly varying analog parameters can be achieved, 
tight limit definitions are required. Frequent 
database updates supported by intensive data analysis 
is needed to maintain the limits. Assuming this can 
be routinely supported, accurate assessment of 
widely varying parameters is seldom achieved. An 
example of a parameter in this class would be solar 
array current for a low earth orbiter. Despite the fact 
that the parameter is well behaved and shows a 
distinctive orbital character, steps are taken to avoid 
frequent erroneous limit violations. This is usually 
done by setting very wide general limits, then 
applying techniques (i.e., conditional limits, etc.) to 
better evaluate the slightly varying segments of the 
data. This process often results in some invalid limit 
violations and loose evaluation of the parameter over 
much of the orbit 

Despite best efforts, the probability of early problem 
detection is not what it should be. To compensate. 
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additional engineering analysis is performed to 
supplement the real-time evaluation. The analysis is 
done to detect potential problems and assess system 
performance. Short, medium and long term trends 
are evaluated against a reference or the expected. 
Unfortunately, lag times and resource requirements 
are high in generating the analysis and transferring 
analytical products to the control center. 

2. OSA CAPABILITIES 

OS A was developed to solve these problems using an 
approach as old as control centers themselves. 
Traditional evaluation often involved a technique 
called "holding two overlapping plots up to the 
light". This produced a qualitative analysis not 
directly storable on magnetic media. OSA takes a 
more integrated and exact approach. The system 
performs a quantitative analysis of current versus 
reference data in real-time or batch modes. The 
reference data is analytically determined and may 
come from any source (i.e., simulator, s/c tape dump, 
etc.). OSA graphically displays reference data, 
current data and user defined variable limits on a 
single plot. More importantly, differences between 
the current and reference data are calculated and 
plotted with user defined difference limits. Limit 
sensing is performed on the difference data, 
violations are reported to the controller in real-time 
and violation statistics are maintained. The process 
significantly increases the control center's ability to 
accurately assess widely varying telemetry. This is 
accomplished by sensing against an analytically 
determined varying limit definition. 

OSA is used to set new limit definitions upon user 
request. The reference data is graphically displayed 
and the user is allowed to segment the data. High 
and low limits are defined for each segment relative 
to the reference data values. Two types of limits can 
be defined. The most frequently selected is a 
percentage of each individual reference value. The 
other option is to apply a fixed offset to each 
reference point. Limit values are usually reviewed 
upon update of the reference image. 

OSA allows the user full management of the 
reference image. Typically, candidate reference data 
is analyzed by OSA and optionally used to update 
the reference image upon engineer approval. Limit 
definitions can be modified. Limit values 
automatically adjust to the new reference data. The 
reference image and limit definitions directly reflect 
the current engineering requirements. Thus, 


detailed analysis can efficiently be transferred to the 
Control Center for real-time use in a painless 
manner. 

3. OSA BENEFITS 

One indicator of a tool’s worth is the amount of 
unexpected benefit that falls out from its use. While 
detecting several problems and identifying other 
curiosities, OSA output supports most GRO 
documentation concerning the power subsystem 
where detailed analysis of orbital behavior is 
required. The OSA archival function has been used 
extensively to compare selected sets of data separated 
in time but collected under similar spacecraft 
conditions. In addition OSA contributes to medium 
and long term statistical data calculation. 

The traditional statistics are calculated for the 
current data and include minimum, maximum, 
mean, standard deviation and variance. Uniquely, 
statistics are calculated for the difference data and 
include average differences, number of samples out 
of tolerance and the maximum number of 
consecutive samples out of tolerance. Statistical 
values for all parameters under evaluation are 
displayed on Statistical Summary Pages. These 
pages are routinely maintained during a contact in 
the real-time environment. Limit violations are 
indicated on these pages via a color coding scheme. 
The graphical displays are available and contain the 
statistics for the plotted parameter. All statistical 
data is available in standard format via magnetic 
media for subsequent analysis. 

OSA has proven itself by the early detection and 
detailed analysis of the GRO (Gamma Ray 
Observatory) MPS-1 battery problems. While two 
missions were experiencing similar problems, GRO 
was able to clearly identify the problem early on and 
define even slight character changes in battery state 
of health indicators. To this date, GRO still provides 
the most detailed data analysis of early battery 
degradation character. This, of course, is important 
to the future. OSA's capabilities are required for the 
earliest detection of problem symptoms. 

The control center's experience with OSA has been 
very rewarding. This is due to the soundness of the 
concept, the quality of the products and the 
professionalism of the developers. 
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4. OSA IMPLEMENTATION 

At start up, OSA menu options allow the FOT to 
provide default settings for manual or automatic 
("sleep mode") analysis and print operations. 

During operation, OSA settings, display ranges, 
manual or sleep mode operation, and navigation 
among mnemonics are controlled through function 
keys. 

The PC version of OSA uses C along with an 
assembly language-based commercial graphics 
package to immediately display or modify graphical 
elements such as orbital signatures, associated 
tolerances, moveable timelines, or tolerance band 
boundaries, even on a 286-based PC. Display ranges 
for parameters may be modified, and the current data 
may be manually aligned with the reference to 
further refine the automatic alignment performed to 
eliminate the effects of nodal precession on the 
current data. 


The TPOCC (Transportable Payload Operations 
Control Center) version of OSA is being developed 
for Hewlett Packard and Sun workstations in C++, 
using OSF/MOTIF, and is X-Window based. 

5. OSA EVOLUTION AND FUTURE 
DIRECTIONS 

OSA is intended to be a real-time telemetry 
monitoring tool for time-varying parameters such as 
power system data for the GRO. OSA was to use 
neural networks trained on orbital signature 
examples that indicated developing problems. In 
this way, OSA could examine either tape recorder 
playback or real-time pass data and flag impending 
problems BEFORE they exceeded critical limits. 

The neural networks were to be trained on simulated 
or hand-estimated data generated before launch. 
Thus the origin of the currently used acronym of 
OSA in the GRO - ESP expert system predictor (as 
shown on Figure 1). 


ESP Orbital Signature Analysis for EM1C1SAI 
Current Orbit 4244 vs. Reference Orbit 4229 
ECLIPSE DATA FOR EVALUATION 

Amps 




<F1> Tolerance Binds OFF 
< F2 > Reference Orbit ON 
Current Orbit 
S/m Sleep on/off OFF 

T toggle auto print OFF 
*-,■* to Move left, right 
<Ctrl> Move fast 

<F5> glob labl , <F6> loci 
<F7> Mark orbit an/'a '£ 
<F8> prev MneM> F10 next 
<F9> redraw screen 
A align, P display range 
C goto HneM, Q to quit 
C save, qui t, resuMe later 
Current Ual : B.4B0 

Reference Ual: 0.400 

Difference : 0.000 

High Tol LiM : 0.440 

Low Tol LiM : 0.360 

Average Diff : -0.134 
Avg Abs Diff : 0.275 

Avg AMt OOT : 0.732 

Cons Nun OOT : 10 


Total 351, 
Offset Rate 
Maxi mum 
Mi n i mum 
Mean 

Variance 
Std. Dev. 


Nun OOT 15 
: 0 
: 18.381 
: 0.200 
: 5.894 

: 30.254 
: 5 . 500 


<F3> Tolerance Bands ON 
<F4> Reference Line OFF 


Differences Plot 


4 Jan 04 23:34:39 1992 


Figure 1. OSA Plot of GRO Solar Array Current Eclipsed By The Sun 
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Five key lessons learned are shown below that 
describe both the development process as well as the 
user (and non-user) reaction to OS A. 

LESSON 1 - A model-based system needs a model 

Simulators are wonderful tools, but for many 
missions and for a variety of reasons, simulators are 
not able to supply the necessary training data for the 
neural networks. For the GRO, the spacecraft 
analyst felt that the predicted power system values, 
while reasonable, were not sufficiently certain to be 
used as the basis for neural network training. 
However, the concept of a reference orbit, as a basis 
for comparing current data, was kept. 

As delivered, OSA uses a previously captured (and 
reviewed and approved) orbit's data as a reference 
for comparison to the current Operationally, the 
reference for the GRO is updated daily using the 
daily orbital data after comparison to the previous 
reference orbit. This works well in practice because 
day-to-day orbital signature variations are small. 
Ultimately, OSA will still use neural networks 
trained on flight data along with auxiliary 
information to recognize developing problems on- 
board the spacecraft, thus living up to its name, ESP. 

LESSON 2 - Prototype, demonstrate, and change - 
continually 

From the developer’s perspective, OSA is a success 
story due in part to excellent customer feedback from 
the many prototype demonstrations performed, but 
also due to constant incorporation of changes or new 
features. No feature, tool, or approach was held 
sacred except the final objective of the system itself. 
Changes were so extensive that the completed offline 
PC-based version of OSA incorporated neither 
neural networks nor used simulator data as originally 
planned but, most importantly, it met the user's data 
monitoring and analysis needs. 

LESSON 3 - For analysts, quantity is more 
important than quality 

Analysts make critical spacecraft operational 
decisions based on the data supplied by various tools. 
They will make use of qualitative assessments if they 
are given the numbers as well. If only one of the two 
can be provided, they want the numbers instead of 
the tool's "expert" assessment of what is happening 
on-board the spacecraft 


OSA/ESP is trusted because it provides analyst- 
selected quantitative measures of the spacecraft 
power system state of health based on analyst- 
assigned tolerances employing an analyst-approved 
reference orbit 

LESSON 4 - The FOT may dislike what the 
spacecraft analyst loves 

The flight operations team and spacecraft analysts 
have different needs. The FOT user desires 
automation of routine activities that include data 
capture, comparison, analysis, and plotting, and 
print and archive. FOT interaction is desired only 
when exceptions are reported that highlight potential 
problems. To that end, saved menu selections, 
predicted event file inputs, statistical summary pages 
and color coded limit sensing are provided by OSA. 
OSA automatically displays and prints statistics as 
well as plots. 

The spacecraft analyst, on the other hand, may wish 
to investigate specific problems, such as out-of- 
tolerance conditions, spotted by the FOT. OSA 
manual navigation features include moving among 
mnemonics, displaying a specific mnemonic, save 
and resume capability, select and set tolerance bands 
and values, modifying display ranges, tolerance 
thresholds, manually aligning current and reference 
orbit signatures, and switching on or off any of the 
automated functions. 

We learned that, if in doubt about which features to 
provide to the typical spacecraft analyst, at a 
minimum, do the following: 

• Capture and plot everything 

• Compute all statistics 

• Archive and print everything 

• Process previously archived data 

• Output data and statistics in "standard" 
formats, ASCII, and format for "standard" 
reports as well 

• Allow any or all of these features to be toggled 
on or off 

• Allow saving of feature settings 
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• Allow for batching or grouping of various 
menu commands to permit hands-off (a.k.a. 
"sleep mode") operation 

• Anything else thought of during the 
prototyping and testing process 

On the other hand, for the FOT, the rules are simple. 
For a tool fated for control center use ensure that the 
tool does the following: 

• Does not require frequent tending 

• Output is reliably correct 

• Return exceeds the effort 

LESSON 5 - The OSA concept is too simple to 
understand. 

We've demonstrated OSA dozens of times both to 
those with control center experience (both FOT 
members and spacecraft analysts), and to those with 
less familiarity with spacecraft operations. Because 
OSA also happens to plot orbital data and generate 
statistics, it is often mistaken for a trending and/or 
plotting package. These and other common 
reactions are listed below followed by a summary of 
our typical response. 

• Doesn't standard limit checking do this 
checking already? No, it essentially just 
performs catastrophic limit checking for time 
varying parameters. 

• An OSA out of tolerance condition does not 
indicate a problem if the value is still within 
the static limits. It most certainly does (we 
cite the GRO battery and the GRO lunar 
eclipse example). 

® We already have a plotting and/or a trending 
package. 

• We already plot out all data for critical 
parameters. 

• We already generate standard statistics for all 
parameters. 

® We already look at the plots of problem 
parameters. 


Rarely, if ever, are the four items above done 
in a single package either is real-time or in 
background. They are by-products of OSA, 
not the product. 

® We don't really need OSA because the only 

thing that it has that our tools currently do not 
is this idea of a reference. You still don't 
routinely (daily and each pass) align and 
compare all critical parameters to their 
respective references and produce a 
quantitative assessment. 

• Isn't there too much change in the orbital 
signature daily? No, while the daily change is 
a fraction of each time-varying parameter's 
static limit range, future enhancements will 
analytically verify changes in spacecraft 
profile allowing OSA to expertly adjust 
tolerances. 

• OSA runs on a PC and will soon run on Sun 
and HP workstations. Couid we use it in our 
control center without many/any changes ? 
Quite possibly. 

6. ENHANCEMENTS UNDERWAY 

Present enhancements currently under development 
include an expert system to modify the reference 
curve and current orbit data according to the 
operational state of the spacecraft, thereby 
accounting for the effect of spacecraft activities 
during curve comparison. Closer alignment of the 
two curves permits even tighter tolerances to be 
assigned. The state change rules are user definable. 
The reference orbits may be hand modified using 
mouse input. Also, patterns of interest may be 
identified using the mouse and searched for by 
neural networks trained on the patterns. 

Finally, the system is being integrated into a new 
NASA/Goddard TPOCC, and will be object oriented 
and Motif compliant, for use on such missions as 
SAMPEX and Wind/Polar. 
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